Systems, methods, devices and arrangements for cost-effective routing

ABSTRACT

A variety of methods, systems, devices and arrangements are implemented for assessing and/or controlling call routing for VoIP/VioIP calls. According to one such method, endpoint devices are used to monitor and/or assess the call-quality. The assessment is sent to a centralized server arrangement and call-routing is controlled therefrom. Endpoint devices employ a decentralized testing mechanism to further monitor and assess call quality including the use of test connections. Aspects of call quality are analyzed and attributed to endpoint devices and/or local connections or networks to distinguish intermediate routing issues from local/endpoint issues.

FIELD OF THE INVENTION

The present invention relates generally to cost effective routing and tosystems, methods and devices for defining and adjusting data routingacross multiple platforms.

BACKGROUND

Voice over Internet Protocol (VoIP) represents a variety of differenttransmission technologies that are used to provide voice communicationsover Internet Protocol (IP) networks, such as the Internet or similarpacket-switched networks. In a general VoIP-based example, a microphoneconverts sound into analog electrical signals. The analog signals arethen converted to a digital form. If desired, compression techniques(e.g., audio codecs that encode speech) are used to reduce bandwidthrequirements. The resulting data is formatted into Internet protocol(IP) packets for transmission over the Internet. The process is reversedat the receiving end eventually producing sound from a speaker.

The connection and disconnection processes that are implemented betweentwo VoIP endpoint devices are sometimes referred to as set-up andtear-down, respectively. This set-up and tear-down of calls isimplemented according to rules defined by various VoIP (and orvideo-based) session control protocols, such as, H.323, SessionInitiation Protocol (SIP), Real-time Transport Protocol (RTP), and/or IPMultimedia Subsystem (IMS).

The growth of Voice-over-IP (VoIP) devices, services and productspresents a number of issues. Call routing is an important considerationin terms of costs for VoIP capable devices. Other issues include callquality factors such as packet loss, packet delay, and packet jitter.

Another expanding area relates to Video-over-IP (VioIP) devices,services and products. Although the data requirements are at leastpartially different relative to VoIP, similar issues with quality anduser experience arise with video transmissions. For instance, packetloss can cause intermittent freezing of a video stream as well asartifacts. Such aspects can be considerably frustrating to a viewer andeven render the video stream unintelligible.

SUMMARY

Aspects of the present invention are directed to routing selections thataddress challenges including those discussed above, and that areapplicable to a variety of voice, video and data applications, devices,systems and methods. These and other aspects of the present inventionare exemplified in a number of implementations and applications, some ofwhich are shown in the figures and characterized in the claims sectionthat follows.

According to one embodiment of the present invention, endpoint devicesare used to monitor and/or assess the call-quality. The assessment issent to a centralized server arrangement and call-routing is controlledtherefrom. Endpoint devices employ a decentralized testing mechanism tofurther monitor and assess call quality including the use of testconnections. Aspects of call quality are analyzed and attributed toendpoint devices and/or local connections or networks to distinguishintermediate routing issues from local/endpoint issues.

Consistent with one embodiment of the present invention, a systemprovides call routing. The system includes a plurality of endpointdevices each having an Internet Protocol (IP) interface, an audio outputfor producing audible sounds, an audio input for converting audiblesounds to electrical signals, and a circuit including at least oneprocessor and programmed software instructions. When the programmedsoftware instructions are executed by the at least one processor, theprocessor performs the steps of measuring a plurality of call qualityfactors for a VoIP call implemented using the IP interface, andpublishing, using the IP interface, data representing the plurality ofcall quality factors. The system also includes at least one server thathas a database containing call-quality metrics and call-cost metrics forvarious call-routing options. The at least one server is configured andarranged for: receiving the published data representing the plurality ofcall quality factors, assigning, to the received data, weight factorsrepresenting different portions of a call route for the VoIP call,respectively, and selecting a call route for a subsequent VoIP callusing an algorithm based upon the assigned weight factors and thecall-cost metrics.

According to another embodiment of the present invention, a Voice overInternet Protocol (VoIP) endpoint device is provided that includes anInternet Protocol (IP) interface; an audio output for producing audiblesounds; an audio input for converting audible sounds to electricalsignals; and a circuit that includes at least one processor andprogrammed software instructions. When the instructions are executed bythe at least one processor, steps are performed that include measuring aplurality of call quality factors for a VoIP call implemented using theIP interface, assigning, to the measured plurality of call qualityfactors, weight factors representing different portions of a call routefor the VoIP call, and publishing, using the IP interface, results ofthe assessment of the plurality of call quality factors.

The above summary is not intended to describe each illustratedembodiment or every implementation of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may be more completely understood in consideration of thefollowing detailed description of various embodiments of the inventionin connection with the accompanying drawings, in which:

FIG. 1 depicts a system for communicating between endpoint devices usingVoIP/VioIP, consistent with an embodiment of the present invention;

FIG. 2 depicts a request/response transaction model, consistent with anembodiment of the present invention;

FIG. 3 depicts a flow diagram for establishing test connections betweenendpoint devices, consistent with embodiments of the present invention;and

FIG. 4 depicts a functional diagram for an endpoint device, consistentwith an embodiment of the present invention.

While the invention is amenable to various modifications and alternativeforms, specifics thereof have been shown by way of example in thedrawings and will be described in detail. It should be understood,however, that the intention is not to limit the invention to theparticular embodiments described. On the contrary, the intention is tocover all modifications, equivalents, and alternatives falling withinthe spirit and scope of the invention.

DETAILED DESCRIPTION

The present invention is directed to routing decisions including routingpacket-based communications over a network, such as the Internet, andrelated approaches, their uses and systems for the same. As discussed inmore detail herein, many aspects of the present invention areparticularly well-suited for Voice over Internet Protocol (VoIP)applications; however, aspects of the present invention are also foundto be useful for Video over Internet Protocol (VioIP) communications(with or without accompanying audio). While the present invention is notnecessarily limited to such applications, various aspects of theinvention may be appreciated through a discussion of various examplesusing this context.

Embodiments of the present invention relate to systems and components ofsystems that work as part of a robust voice call-routing solution.Aspects of the invention are implemented at various points in a callsystem that provides VoIP/VioIP call services. Endpoint devices, whichprovide call functions directly to a human user, communicate with oneanother using VoIP/VioIP servers that provide call-lookup, proxyfunctionality, NAT traversal and other functionality. Particularimplementations also relate to routing of video communications betweenendpoint devices. While the transmitted data and specific data protocolsused to format and send the data may differ, video and audio callssometimes use many of the same underlying protocols for establishing andmaintaining data connections (e.g., similar setup and teardownprocedures). Aspects of the present invention relate to call-routingdecisions made by a centralized server that services multiple endpointdevices.

Various embodiments relate to providing highly-scalable solutions, whichleverage off of the increasing complexity and quantity of endpointdevices with VoIP/VioIP capabilities. In certain embodiments, theendpoint devices can be configured to facilitate data collection and tooffload some of the processing from the centralized server. Otheraspects relate to decentralized call-routing decisions made by theendpoint devices. The various components can be implemented alone or incombination as should be apparent from the many possible combinationsthat are discussed herein. Such discussions, however, are not limitingand variations thereof are possible.

As discussed herein, various embodiments of the present invention relateto the use of call-quality metrics and call-cost metrics in selection ofa routing path. Particular implementations are relatively robust andflexible allowing for use of many different underlying algorithms andmethods. For instance, U.S. Pat. No. 7,352,852, to Cocherl, et al. andissued Apr. 1, 2008; and U.S. Pat. No. 7,339,934 to Mussman et al. andissued Mar. 4, 2008, each describe example least-cost routing algorithmsand uses thereof. U.S. Pat. No. 7,222,190, to Klinker, et al. and issuedMay 22, 2007, describes various performance metrics for IP-basedtransmission including an Exponentially Weighted Moving Average (“EWMA”)method that establishes a moving threshold based on historic samplingthat places an exponential weighting on the most recent samples. Each ofthese documents is fully incorporated herein by reference. These andother metrics can be used in connection with various embodiments of thepresent invention. For instance, aspects of the present invention allowfor various factors, otherwise used in determining these call-qualitymetrics, to be attributed to endpoint devices and/or their immediateconnection points and networks. Such factors can then be removed ordiscounted (e.g., by weighting) from consideration by the selectedalgorithm(s). In this manner, the results more accurately representintermediate call route issues as opposed to local-route/endpointissues.

According to one embodiment of the present invention, VoIP (or VioIP)capable endpoint devices (e.g., hand held devices, home computers orVoIP telephones) establish a VoIP/VioIP connection to another deviceover a particular call route. A call quality metric is determined forthe call and associated with the particular call route. For futurecalls, call-routing decisions are made using an algorithm that can beconfigured to consider a variety of factors. A few factors include, butare not necessarily limited to, the call quality metric, financial costsassociated with the routing, the type of service plan associated withthe endpoint devices, the time of day and the type of endpoint device.

Call quality metrics can be designed as a function of a number ofparameters. Example, non-limiting, parameters include jitter, packetloss, echoing and latency. Latency can be caused by delay factors, suchas jitter buffer delay, propagation delay, transport delay andpacketization/coding delays. Jitter buffer delay is caused by storage ofreceived data in a buffer useful for compensating for varying arrivaltimes of data. Propagation delay represents the time necessary for adata signal to physically traverse the network between two endpointdevices. Transport delay represents the delay necessary to traverse thevarious network devices within a data path. Packetization/coding delaysare caused by data formatting and can include time necessary forconversions between analog and digital, compression and formatting ofdata into packets.

According to one embodiment of the present invention, the endpointdevices monitor call parameters during a call. Once the call iscompleted, the endpoint devices send the monitored call parameters to aremote server. In a particular implementation, the end point devices cansend a Session Initiation Protocol (SIP) publish message that includes,within the body of the message, a call quality metric and/or themonitored parameters. The remote server then uses this data to determinepreferred call routing for endpoint devices making subsequent calls.

In a particular implementation, the poor call quality metric results areattributed to specific portions or aspects of the call route. Forinstance, poor connections between an endpoint device and a localrouter, LAN or modem are a common cause of poor quality metric results.Thus, a quality metric for a particular endpoint device can be a poorindicator of the quality of a particular route for another endpointdevice, particularly where the other endpoint device uses a differentlocal connection point. Moreover, if the individual connection point isa significant cause of poor call quality, modifying call routing thatoccurs after the initial connection point may not solve the problem withthe call quality. Accordingly, aspects of the present inventiondistinguish between different portions of the call route and attributequality ratings to the respective portions. Intelligent call-routingdecisions are then made using this additional data.

Certain symptoms of poor call quality are more likely to be caused by anindividual connection point issue. For instance, bandwidth-relatedproblems tend to be caused by individual connection point. Poorconnections, connections to a bandwidth-limited service plan and/orheavily loaded connection points can limit effective bandwidth. Poorconnections (wired or wireless) cause data to be corrupted or lost andthereby result in dropped or lost packets. Connection points vary inavailable bandwidth, which can reduce the call quality. Heavily loadedconnection points can be caused by applications running on the endpointdevice (e.g., file-sharing programs or malware/spyware) and otherdevices using the same connection point. Heavily loaded connectionpoints cause a reduction in the available bandwidth. In another example,unwanted echoes are often caused by feedback or other problems withinthe endpoint device (e.g., poor lighting for video, feedback fromspeaker to microphone, electromagnetic crosstalk or poorspeaker/microphone termination), as opposed to call routing, and can beattributed accordingly. Repeatedly poor latency can often be associatedwith problems in the call route and attributed in this fashion.

It should be noted that general tendencies of a particular symptom arenot determinative and that many, if not most, symptoms can have severaldifferent causes. Accordingly, a particular implementation uses thesymptoms to determine a weight factor for respective portions. Thisweight factor is then used as a correlation between a call qualitymetric and a respective portion. Strongly correlated portions suggestthat the portions are a likely cause of a poor quality metric. Thisdetermination can be carried out by the endpoint devices or by one ormore centralized servers. For instance, the endpoint devices couldattribute a poor quality metric as 10% endpoint device, 70% localconnection and 20% remote routing. This information could be locallystored and/or transmitted to a remote server.

The number of VoIP/VioIP capable devices is rapidly increasing due inpart to increased usage of mobile/handheld devices with Internetcapabilities. The mobility of the devices can complicate the ability tomonitor and assess the likely source of poor call quality. For instance,mobile devices may connect to multiple different connection pointswithin a single day. Each connection point can exhibit a differentconnection quality and use a different call route. The routing beyondthe connection points can range from virtually identical or completelydifferent, e.g., depending upon the relative location of the connectionpoints. Moreover, the true connection point can be hidden and difficultto ascertain when, for example, the mobile device connection point is toa private network that uses NAT, firewalls and the like. As such,identification of the endpoint device does not necessarily correlate toa particular, or static, connection point.

One aspect of the present invention relates to an application that canbe implemented on such mobile devices. Recognizing that the mobiledevice has visibility of the initial connection point and privatenetwork associated therewith, the mobile device tracks used connectionpoints and an indication of the call quality metrics for the connectionpoints. When establishing a new call, the application can make aninitial routing decision based upon the stored call quality metric forthe current connection point.

As an example, a mobile endpoint device may connect to a first wirelessnetwork access point and make a VoIP/VioIP call using this connection.The call quality metric of this call is recorded as being poor, andparticularly, having quality factors that suggest that the connectionpoint is a limiting factor. If the mobile device has other connectioncapabilities, such as cellular, PSTN, wired IP connections, or otheravailable wireless networks, the mobile device can opt to use thoseconnections. Another routing option is the selection of a particularVoIP/VioIP connection server or proxy. VoIP/VioIP servers may havepreferences in terms of monetary costs (whether user or provided costs)to competing voice quality preferences (e.g., due to server performanceor network location). Thus, if the voice quality metric for a particularconnection is poor, the mobile device can select a server with a betterquality metric over another server. Thus, the connection may exhibit ahigher monetary cost but also have a higher quality metric.

Routing selections by the mobile device can be performed by applying auser profile that contains data regarding the respective costs of thedifferent connection options. The application accesses this user profilein combination with the recorded quality metrics to determine thedesired connection and/or call route. In a particular implementation,the user profile is controlled by the (VoIP/VioIP) service provider. Theservice provider is then able to perform offline analysis of theVoIP/VioIP service and adjust the user profiles accordingly. This allowsfor the service provider to control various aspects (e.g., server loads,overall voice quality or call-related costs) in combination with adistributed routing decisions system that uses the endpoint devices toimplement call-routing decisions.

Another aspect of the present invention relates to an endpointapplication (EA) that is designed to provide an interface foruser-developed applications. User-developed applications are becomingincreasingly useful. These applications can greatly increase the valueof a particular service or device often in ways not originallycontemplated. They also provide users with endless customizations andpersonalization of the product or service. The EA provides an interfaceto affect the routing decisions. This allows such user-developedapplications to provide some level of input and control over the routingdecisions. The service provider determines the precise amount of controlgiven to the user application by the EA. Allowing the user-developedapplication to have less control means that the service provider is ableto exhibit more control over how the calls are routed. Allowing theuser-developed application to have more control increases the potentialfor different types of user applications.

User-developed applications can be organically created by individuals orgenerated by companies for download. For example, a number of VoIPapplications are currently available for providing VoIP connections withcellular phones (e.g., Fring, Talkster, Nimbuzz or Barablu). Suchapplications can interface with the EA to provide customizable routingdecisions.

One component of the EA is designed to provide an application interfacethat receives an input representing the importance of quality vs. costto the user. The input could be a value on a scale (e.g., scale of 1 to10 with 10 representing the highest quality importance, with littleregard for cost). The EA receives the input and uses it as part of therouting decision. The EA can directly perform the routing decision basedupon the input and/or forward the input to a remote server for routingdecisions. The user-designed application could provide a value for theinput based upon nearly any criteria. For example, the user applicationmay designate calls to certain numbers (e.g., personal calls) as havinglower priority of quality while others (e.g., business calls) have ahigher priority of quality. Video could be given a lower priority thanaudio and vice versa. Another EA might automatically detect a physicallocation or a logical location (e.g., GPS-determined location or aconnection-point-determined location) for the mobile device and adjustthe input accordingly. The EA could also simply allow the user todirectly set the input value through a graphical user interface (GUI).

Implementations of the EA receive, from the user application, inputsrepresenting the importance of a number of different call-quality andcall-cost criteria. For instance, the user application could indicatethat jitter is highly important, while echoing is not as important. Inanother instance, the application could indicate that all factors areequally important.

The EA can also be designed to allow the user application to add one ormore custom factors. Thus, the EA will continue to monitor jitter,packet loss, echoing and latency (and other factors) during calls;however, the user application can introduce additional factors stored aspart of the call quality assessment. For instance, the user applicationcould monitor audio-frequency components of the call or some otherfactor as yet undetermined. The input would then be added as a componentof the call quality metric for the user's endpoint device and thereby beused as part of subsequent call routing decisions. One mode of the EAeven allows the user application to fully control, set or define thealgorithms used to determine call quality and/or the routing decisions.

The EA can set the level of control in response to a number ofmechanisms. One such mechanism involves a tiered-service structure. Inthis manner, the EA provides additional control to users that havehigher service plans.

Embodiments of the present invention also allow the endpoint devices touse various diagnostic procedures to help assess the likely cause ofpoor call quality. One such diagnostic procedure relates toendpoint-based problems with transmitting or receiving data packets. Forexample, insufficient processing power (e.g., due to design and/or otherapplications demanding processing resources) can result in degraded callquality. To help quantify such endpoint-related factors, the endpointenters a diagnostic mode. In the diagnostic mode, the endpoint transmitsa pseudo-data stream to itself. This can be accomplished using aloopback IP address (e.g., 127.0.0.1) as defined in the IP standards.Quality factors for the loopback transmission are measured accordingly.Problems incurred during this loopback transmission are largely limitedto problems of the endpoint device. Thus, poor quality indications canbe attributed to the endpoint device with high confidence. The qualityindications from an actual call can then be adjusted to account for theendpoint device's internal quality factor. In this manner, the systemcan discount such endpoint device issues when assessing a particularcall route.

While the circuit/processor measurable factors, such as jitter, packetloss, latency and echo, provide a good indication of call quality, theydo not perfectly model the call quality perceived by a person using anendpoint device. Thus, the EA also uses input from users to assess anddefine the quality of a call route. In one implementation, the EAprompts a user to provide call-quality feedback (e.g., rate call from 1to 10) and use this information as part of the call-quality assessment.

User participation, however, is sometimes difficult to obtain, and thus,the EA can be configured to obtain user input in other manners. Aparticular implementation takes advantage of mobile devices that havemotion sensing components, such as gyroscopes. When a user experiencesbad call quality, the user is encouraged to shake the device. Theshaking indicates to the EA that the user may be experiencing poor callquality. If the shaking coincides with other indications of poor callquality, then the EA can be relatively certain that the user isproviding negative feedback regarding the call quality. Userparticipation is encouraged because it is believed that shaking thedevice is a natural response that requires less time and considerationthan asking the user to input a numerical value. Moreover, the EA canrespond to the shaking by attempting to establish a connection via adifferent call route. Once established, the EA can seamlessly switch theconversation to the second call route. If the user is aware of thisgeneral feature, it provides additional incentive to provide feedback byshaking as the shaking may result in an improved connection due to thisre-routing of the call.

Although not limited thereto, a few example call quality metrics includeMean Opinion Score (MOS), ITU P.861 (Perceptual Speech Quality Measureor PSQM), ITU P.826 (Perceptual Evaluation of Speech Quality or PESQ),ITU P.563, or ITU P.800 (Perceptual Analysis/Measurement System or PAMS)as well as variations and combinations thereof. Example video qualitymetrics include, but are not limited to, ITU-T Rec. J.246 (RR) and J.247(FR).

Collection and analysis of data obtained during active calls is apowerful tool in assessing call quality as a function of call routing;however, aspects of the present invention allow for active testing ofcall-routing parameters. In a particular implementation, when poor callquality is detected, additional information regarding the call route inquestion can be actively obtained.

One mechanism for actively obtaining call route information involves useof additional endpoint devices to dynamically test the state of thenetwork by testing various call routes. These additional endpointdevices transmit test data along one or more data routes. The test datacan be used to define the voice quality provided by a particular dataroute. This testing can be implemented in response to poor call qualitybeing detected by a particular endpoint device. In certainimplementations, this allows for the test to be conducted while a callassociated with the particular endpoint device is still ongoing. Thevarious quality metrics can then be directly correlated in time, whichcan be useful in determining a likely cause of poor call quality. Forinstance, a VoIP/VioIP server can identify an endpoint device that has asimilar or identical location to the current endpoint device. TheVoIP/VioIP server can then request a test connection with theidentified-test endpoint device. The test endpoint device transmits datapackets to and receives data packets from the VoIP/VioIP server. Thecall quality metric of this connection can be compared to that of theendpoint device that originally detected the poor call quality. If thecall quality of the test connection is significantly better than that ofthe original connection, then portions of the route shared between theconnections are less likely to be the main cause of the poor quality.

In another implementation, the original endpoint device can beconfigured to perform a test connection after completion of thepoor-quality connection. The endpoint device requests a connection to aVoIP/VioIP server designed to receive and establish test connections. Ina particular embodiment, the test connection can be implemented as abackground application that the user of the endpoint device need not beaware of. The endpoint device can establish and complete the testconnection over a relatively short time duration, which can beparticularly useful for limiting processor or network loading that wouldbe associated with the test connection.

In another implementation, the endpoint device can implement a testconnection by contacting and connecting to other endpoint devices. Thiscan be particularly useful for facilitating a scalable solution thatuses distributed testing. For instance, using a centralized test serverrequires increasing network bandwidth and processing bandwidth as thenumber of requesting endpoint devices increases. A distributedarchitecture, however, naturally scales because test-requesting endpointdevices are also test-receiving endpoint devices.

Connections between two test endpoint devices can be facilitated using aVoIP/VioIP server. A requesting endpoint device contacts the VoIP/VioIPserver to indicate a desire to establish a test connection. TheVoIP/VioIP server identifies a suitable endpoint device and providesconnection information back to the requesting endpoint device.Alternatively, endpoint devices can obtain one or more test endpointdevices from a streamed list of test endpoint devices. A VoIP/VioIPserver can transmit a multicast stream according to the IPv6 multicaststandard. The multicast stream includes a list of endpoint devices. Arequesting endpoint device can subscribe to the multicast stream toobtain one or more endpoint devices with which to establish a testconnection. In a particular implementation, multiple multicast streamscan be provided and subscribed to according to desired parameters. Themulticast streams can represent different locations of endpoint devices,different types of endpoint devices, different capabilities of endpointdevices or any other desirable distinction. Testing endpoint devicesprovide such test results to a VoIP/VioIP server (e.g., using SIPpublish message) and can also keep the results for local routingdeterminations.

Turning now to the figures, FIG. 1 depicts a system for communicatingbetween endpoint devices using VoIP/VioIP, consistent with an embodimentof the present invention. Telephone devices 102, 104 connect directlywith local Public-Switched-Telephone Networks (PSTNs) 106, 108. Astandard telephone call can be completed between such devices using thetraditional telephone service. Private Branch Exchange (PBX)-baseddevices 110, 112, 114, 116, 118, 120, connect directly with PBX 122 or124. The PBX-based devices can include any number of different devicesincluding, but not limited to, analog telephones, digital telephones,Internet-enabled handheld devices, workstation computers, faxes andBRI-enabled devices. PBXes 122, 124 can provide direct connection to thestandard telephone network via local PSTNs 106, 108 and/or connectionsto data network/Internet 126. They can also provide various callingfeatures, such as call forwarding, extension dialing, programmablecaller-ID, auto attendant and interactive voice response, to name a few.Internet-PBXes (IPBXes) 128, 130 provide PBX functions to devices whileestablishing VoIP/VioIP connections. An IPBX can provide services forlocal devices 132 and/or to remote endpoint devices 134, 136, 138. Forexample, the IPBX can be configured to receive calls destined for orarriving from remote devices that are associated with the IPBX.

The VoIP/VioIP quality server 140 receives, stores and analyzes callquality data received from various devices. For example, remote endpointdevices 134, 136, 138 establish connections between one another or toother endpoint devices (e.g., devices 102, 104, 110, 112, 114, 116, 118,120 or 132). The endpoint devices monitor the quality parameters of aparticular call. This data is then sent to the VoIP/VioIP quality server140 for analysis using, for example, a SIP publish message. Futurerouting can be controlled using results of the analysis by VoIP/VioIPquality server 140. As an example, a VoIP/VioIP call routing server (notshown) can use data generated by the VoIP/VioIP quality server 140 tocontrol call-routing for various ones of the endpoint devices.

Consistent with various embodiments, the system distinguishes betweencall quality issues associated with the endpoint devices and the initialconnection point from call route-related issues. The VoIP/VioIP servercan assign weight values to correspond to a determined percentage ofcall-related issues associated with each portion of the call (e.g.,endpoint device issues, connection-point issues or network node issues).

In particular implementations, the endpoint devices can establish testconnections between one another. The endpoint devices can sendpre-defined test data to help isolate quality problems associated withthe endpoint device from call route problems. For instance, qualityeffects due to poor speakers, microphones and circuitry for conversionsof audio between analog and digital domains would be lessened or removedentirely during such test transmissions.

In one embodiment of the present invention, the endpoint devices receivea list of devices available for test connections by subscribing to amulticast session. The device can receive a partial list, a completelist or a single device. The selection of an appropriate device can berandom or attributed to characteristics of the devices, which can alsobe provided as part of a multicast stream.

FIG. 2 depicts a request/response transaction model, consistent with anembodiment of the present invention. The transaction model is consistentwith SIP protocols, but the specific connection steps and protocolsbetween the endpoint devices need not be so limited. The invention isinstead sufficiently robust to be compatible with various other existingand future protocols.

An originating endpoint device desires to establish a connection with adestination endpoint device. In a specific implementation, theconnection is started when a user dials a telephone number thatindicates a desired endpoint device or user to contact. The originatingendpoint device sends an invite command that identifies the destinationendpoint device (e.g., using a telephone number or IP-address).Optionally, proxy/routing server 1 and 2 serve to control the connectionprocess. Proxy servers receive connection requests and forward them onbehalf of the requestor. Proxy server 1 receives the invite command andsends a trying response back to the originating endpoint device. Proxyserver 1 determines the location of the destination endpoint device. Incertain instances, the destination endpoint device is also behind aproxy server, in this case proxy server 2. Proxy server 1 forwards theinvite request to proxy server 2, which responds with a trying response.Proxy server 2 identifies the IP address of the destination endpointdevice and forwards the invite request thereto. The destination endpointdevice receives the invite request and alerts a user of the endpointdevice (e.g., the endpoint device/phone rings). The destination endpointdevice sends a ringing response, which is routed back through the twoproxies. Should the destination endpoint device user answer the call,the destination endpoint device transmits an O.K. response thatindicates the call is being answered. Upon receipt of the O.K. response,the originating endpoint device sends an acknowledge response whichallows a bidirectional media stream to be established between endpointdevices. Upon completion of the call, a sequence of bye and O.K.responses are sent.

During the call, and particularly during the bidirectional media streamphase, one or more of the endpoint devices can monitor call qualityparameters. Upon completion of the call (or even during the call), themonitored parameters can be published to a VoIP/VioIP call qualityserver using, for example, SIP-based publish messages. The VoIP/VioIPcall quality server can then process the received data and, ifdesired/necessary, send call-routing updates to the proxy servers.

In certain embodiments, endpoint devices can establish test connectionsto help quantify and assess call-quality issues. To establish suchconnections, the endpoint devices need to determine what device toconnect with. In a first implementation, a VoIP/VioIP test servertransmits a list of test-connection endpoint devices using a multicaststream. This multicast stream can be consistent with IPv6 specificationwhich allows for intelligent routing by IP routers. For instance, IProuters forward multicast streams only if a downstream device hassubscribed to the multicast stream.

In another embodiment, the endpoint devices can establish testconnections by sending a connection request to one or more predeterminedtest connection addresses. A VoIP/VioIP server is associated with thetest connection address and can forward the connection request on toavailable endpoint devices. For instance, an originating endpoint devicecan send a test connection request to an IP-address/port combinationthat routes the call to a VoIP/VioIP server while also identifying therequest as a test-connection. The VoIP/VioIP server selects from avariety of other endpoint devices and forwards the test-connectionrequest to this device, thereby acting as a proxy server. The endpointdevices then proceed to send test data and to monitor the call qualitythereof.

FIG. 3 depicts a flow diagram for establishing test connections betweenendpoint devices, consistent with embodiments of the present invention.Endpoint devices 302 and 304 have the capability of establishingVoIP/VioIP communications over network 308. As discussed herein, callrouting decisions are made based upon call quality metrics measuredduring calls. Moreover, test connections can be established between twoendpoint devices.

Such test connections can be particularly useful as they allow for anumber of variables to be isolated or removed from contributing factorsof poor call quality. For instance, the endpoint devices can transmitpredetermined or (randomly) generated test-data during a testconnection. The call quality metrics on such data are independent ofaudio issues with speakers, microphones and audio processing. Thisallows the test to isolate problems associated with sound generationand/or capture from transmission problems. In another instance, the useof data that can be easily quantified helps isolate perceivedcall-quality problems that are not due either to the call route or tothe endpoint devices. For instance, background noise, poor placement ofthe microphone (e.g., relative to a user's mouth) or user hearingproblems can each result in perceived call-quality problems. Sendingdata that is unaffected by any of these issues allows for increasedaccuracy in the testing of particular call-routing paths.

To establish a test connection, an originating endpoint device mustfirst select/determine/discover another endpoint device with which toconnect. One method allows an endpoint device to request informationabout such an endpoint device from a server 306. The server can returnconnection information (e.g., telephone number or IP address) about oneor more endpoint devices 310 with which the originating endpoint devicecan connect. The originating endpoint device can then contact andestablish a connection with one of the provided endpoint devices. Theoriginating endpoint device sends a connection request that indicatesthat a test connection is desired. For instance, SIP allows for arequest to include a definition of the nature of a request as part ofthe protocol. The destination endpoint device can therefore implementthe test connection in the background and, if desired, without userinteraction. Thus, the destination endpoint device does not ring orotherwise indicate a call is inbound. In some instances, the destinationendpoint device can reject a test call. This may be the case where, forexample, the destination endpoint device is operating on battery powerthat is low or where the destination endpoint device is engaged inoperations that would be adversely affected by a test connection, e.g.,operations requiring significant processing power or network bandwidth.

While the above mechanism for obtaining a list of available endpointdevices works well in many situations, as the number of requestingdevices grows, so too does the load on the server that responds to therequests. One aspect of the present invention provides a highly-scalablesolution involving the use of multicast protocols, such as those builtinto the IPv6 standard. In particular, a multicast stream can beestablished by a server. Downstream routing, however, is controlled viathe routing nodes of the network. The routing nodes forward themulticast stream only in the event that a device has subscribed to themulticast stream at some location beyond the routing node. In thismanner, the originating server does not see a significant increase inbandwidth or server loading as the number of subscribing devicesincreases.

In a particular embodiment, the server 306 can provide a number ofdifferent multicast streams (e.g., multicast streams 1, 2 and 3 of FIG.3), each including a different list of available endpoint devices forconnection therewith. The originating endpoint device 302 subscribes toone or more of the multicast streams to receive the available endpointdevices. The example depicted in FIG. 3 shows endpoint device 302subscribing to multicast stream 2 and receiving the corresponding data,which includes endpoint device 304. The endpoint device 302 thenestablishes a test connection with endpoint device 304 and then can(SIP) publish any call-quality metrics obtained from the test.

The different multicast streams can be defined using a variety offactors. One such factor includes different logical orphysical/geographical locations of the endpoint devices. An originatingendpoint device can thus select a location to specifically test routingthereto. As other, non-limiting examples, the different multicaststreams can represent different types of endpoint devices (e.g., homecomputer, laptop or cellular telephones), different connection types(e.g., T1, modem or wireless) or different software versions.

In other embodiments, separate multicast streams can be provided forupdates to the devices. These updates can include changes to the testdata sent between devices, changes to the testing criteria used toassess call quality and/or various software updates. In a particularimplementation, each device maintains a locally-stored list thatcontains version data for various updatable components. The devices canperiodically subscribe to a multicast stream that contains acorresponding list of the most current version of updates available. Theendpoint device can compare the locally-stored list with the multicastlist. If the endpoint device determines that an update is available, theendpoint device can subscribe to a corresponding multicast stream.

The use of such multicast aspects can be particularly useful foraddressing issues related to the (lack of) scalability for variousVoIP/VoIP-related products and services.

FIG. 4 depicts a functional diagram for an endpoint device, consistentwith an embodiment of the present invention. Endpoint device 402provides a number of functions including implementation of aVoIP/VioIP-related protocol stack 404. This stack 404 can conform to anynumber of suitable protocols. The example stack 404 is consistent withan H.323 approach, but the endpoint device need not be so limited.

A user of the endpoint device 402 communicates with a remote userthrough various input/output ports 406 and 408. For instance, aVoIP/VioIP capable phone would include some type of speaker arrangementfor an output and a microphone for an input. Signals to and from thespeaker/microphone can be conditioned and/or converted between digitaland analog realms using audio/visual processing circuitry 410 and 412.This data can be received and transmitted to a control application forprocessing according to the protocol stack 404. A quality metric/callrouting application 414 monitors the quality of a call. As discussedherein, the quality metric application 414 uses a set of call-qualityfactors and/or weights, which can be stored in a local memory ordatabase 416. In certain embodiments, application 414 can also make callrouting decisions based upon stored call-quality metrics, routingalgorithms and/or monetary call-costs data.

Consistent with one embodiment of the present invention, anendpoint-application (EA) interface 418 provides a defined structure forusers wishing to generate EAs 420 and 422 for interfacing with andcontrolling call routing and/or call quality metrics. The EAs allowusers to develop applications for a variety of applications within theparameters established by the EA interface 418. This can includemultiple EAs running on a single endpoint device.

Test-connection application 424 controls the establishment of testconnections useful for characterizing call quality metrics and relatedissues. Test-connection application 424 can respond to an incoming(VoIP/VioIP) connection request that includes a test-connectionindication within the connection request. This allows for thetest-connection application 424 to establish connections withoutbothering a user of the endpoint device. The test-connection application424 can also initiate a test connection by accessing a memory/database426 storing a test-connection endpoint list. In one implementation, thislist can be obtained from a server, which can optionally provideendpoint list(s) using multicast stream(s).

Once a test connection is established, test-connection application 424transmits and receives data using the test connection. This data can bestored in memory/database 426. The data can be designed to simulate datatransmitted during a typical (VoIP/VioIP) connection between endpointdevices and/or specifically constructed to test other aspects. Forinstance, the data can be designed to test bandwidth problems,processing-power issues and the like. In addition to test connections,test-connection application 424 can perform internal testing of variouscomponents of the endpoint device. This can include processor loading,memory availability, loopback tests of audio circuitry, loopback testingof protocol stacks and various other tests.

Test-connection application 424 can then use the test results to modifythe parameters used to determine the call-quality metrics. For instance,a test may indicate that the endpoint device lacks processor power. Poorcall-quality metrics of calls would thereafter be attributed to theendpoint device (rather than a call-routing issue) assuming the testedfactors of the metric are consistent with a lack of processing power.The published call quality metric could include such an indication,which allows the receiving call-routing server to properly attributepoor-call quality metrics to the endpoint device.

The various aspects of the present invention can take a variety of formsand be implemented according to a number of different embodimentsincluding, but not limited to, a storage medium storing with executableinstructions, computer processors configured with executableinstructions, programmable logic, hardware circuit logic andcombinations thereof.

The various embodiments described above are provided by way ofillustration only and should not be construed to limit the invention.Based upon the above discussion and illustrations, those skilled in theart will readily recognize that various modifications and changes may bemade to the present invention without strictly following the exemplaryembodiments and applications illustrated and described herein. Forexample, the methods, devices and systems discussed herein may beimplemented in connection with voice-over Internet services, streamingmedia and call-processing. The invention may also be implemented using avariety of approaches such as those involving a number of differentoperating systems and software programs/packages. Such modifications andchanges do not depart from the true spirit and scope of the presentinvention, including that set forth in the following claims.

What is claimed is:
 1. A system for providing call routing, the systemcomprising: a processor circuit; at least one server including theprocessor circuit and configured to: retrieve call quality datarepresenting a plurality of call quality factors for a plurality of VoIP(Voice over Internet Protocol) calls, each call quality factorrepresenting a call quality for a corresponding call route, identify aparticular call from the plurality of VoIP calls based upon theplurality of call quality factors indicating poor call quality for theparticular call, select, in response to identifying the particular call,a VoIP capable device, request a test connection to the selected VoIPcapable device; compare a plurality of call quality factors for the testconnection with the plurality of call quality factors indicating poorcall quality for the particular call, assign, based upon the comparingof the pluralities of call quality factors, a plurality of differentweight values to each call quality factor for the particular call, eachweight value signifying a likelihood that the quality indicated by acall quality factor is caused by a corresponding portion of a call routefor the particular call, and select a second call route for a subsequentVoIP call using an algorithm based upon the plurality of differentweight values.
 2. The system of claim 1, wherein the at least one serveris further configured to: compare the call quality for the testconnection to the call quality for the particular call, and determine,based upon at least comparing the call qualities, the weight values forthe particular call.
 3. The system of claim 1, wherein the at least oneserver is further configured to: request the test connection to theselected VoIP capable device while the particular call is ongoing. 4.The system of claim 1, wherein the selected VoIP capable device is anendpoint for the particular call.
 5. The system of claim 1, wherein theat least one server is further configured to: select the VoIP capabledevice based upon a location for another VoIP capable device that is anendpoint for the particular call.
 6. The system of claim 1, wherein theat least one server is further configured to send and receive test datapackets from the selected VoIP capable device using the test connection.7. The system of claim 1, wherein the at least one server includes aVoIP/VioIP server that is configured to: receive SIP(session-initiation-protocol)-based publish messages from VoIP capableendpoint devices used in the plurality of VoIP calls, the SIP-basedpublish messages containing the plurality of call quality factors forthe plurality of VoIP calls; and send, in response to the plurality ofdifferent weight values, updates to proxy servers that are configured tocontrol a connection process for the plurality of VoIP calls.
 8. A Voiceover Internet Protocol (VoIP) endpoint device comprising: an InternetProtocol (IP) interface; an audio output circuit for producing audiblesounds; an audio input circuit for converting audible sounds toelectrical signals; and a logic circuit including at least one processorand programmed software instructions that, when executed by the at leastone processor: measure a first plurality of call quality factors for aVoIP call implemented using the IP interface, request, from a VoIP testserver, a list of at least one endpoint device for establishing a testconnection, receive, from the VoIP test server, the list of at least oneendpoint device for establishing a test connection, established, basedupon the received list and using the IP interface, a test connectionwith a particular endpoint device from the list, and measure a secondplurality of call quality factors for the test connection.
 9. The VoIPendpoint device of claim 8, wherein the VoIP endpoint device is furtherconfigured to publish the first and second plurality of call qualityfactors using session-initiation-protocol (SIP)-based publish messages.10. The VoIP endpoint device of claim 8, wherein the VoIP endpointdevice is further configured to request the list by subscribing to amulticast stream.
 11. The VoIP endpoint device of claim 8, wherein theVoIP endpoint device is further configured to send test data during thetest connection with a particular endpoint device from the list, whereinthe test data does not include data received from the audio inputcircuit.
 12. The VoIP endpoint device of claim 8, wherein the VoIPendpoint device is further configured to establish a loopback testconnection and to measure a third plurality of call quality factors forthe loopback test connection.
 13. The VoIP endpoint device of claim 8,wherein the VoIP endpoint device is further configured to: receive anincoming test connection request, establish another test connection, andmeasure a third plurality of call quality factors for the another testconnection.
 14. The VoIP endpoint device of claim 13, wherein the VoIPendpoint device is further configured to establish the another testconnection without first ringing.
 15. A method for providing callrouting, the method comprising: using at least one server, that includesa processor circuit, to: retrieve call quality data representing aplurality of call quality factors for a plurality of VoIP (Voice overInternet Protocol) calls, each call quality factor representing a callquality for a corresponding call route, identify a particular call fromthe plurality of VoIP calls based upon the plurality of call qualityfactors indicating poor call quality for the particular call, select, inresponse to identifying the particular call, a VoIP capable device,request a test connection to the selected VoIP capable device; compare aplurality of call quality factors for the test connection with theplurality of call quality factors indicating poor call quality for theparticular call, assign, based upon the comparing of the pluralities ofcall quality factors, a plurality of different weight values to eachcall quality factor for a particular call, each weight value signifyinga likelihood that the quality indicated by a call quality factor iscaused by a corresponding portion of a call route for the particularcall, and select a second call route for a subsequent VoIP call using analgorithm based upon the plurality of different weight values and thecall quality factors.
 16. The method of claim 15, further comprisingusing the at least one server to: compare the call quality for the testconnection to the call quality for the particular call, and determine,based upon at least comparing the call qualities, the weight values forthe particular call.
 17. The method of claim 15, further comprisingusing the at least one server to: receive SIP(session-initiation-protocol)-based publish messages from VoIP capableendpoint devices used in the plurality of VoIP calls, the SIP-basedpublish messages containing the plurality of call quality factors forthe plurality of VoIP calls; and send, in response to the plurality ofdifferent weight values, updates to proxy servers that are configured tocontrol a connection process for the plurality of VoIP calls.